According to a service-oriented architecture, a backend service layer provides services (i.e., business functionality) to service consumers. FIG. 1 is a block diagram illustrating one such scenario. Typical service consumers use this business functionality to provide user interfaces, application-to-application or business-to-business integration, output management (e.g., printing), spreadsheet download, etc. Service consumers of different types, or even of a same type, may access the backend service layer in different ways. Therefore, the services are not particularly adapted to the requirements of any particular service consumer.
User interface client applications typically conform to a data model suited to implementation of a user interface. For example, a user interface implementation is typically concerned only with user interaction and exposure of data and events on the user interface. In contrast, little or no business logic needs to be executed at the client level.
However, even if the logic behind a user interface consists primarily of changing data or triggering events, the processing of a user interface request requires execution of particular steps in the backend service layer. The backend service layer exposes complex services to orchestrate underlying business logic and transaction handling. For example, each user interface request typically requires multiple service calls in the backend to execute steps, such as, but not limited to: modification of data; execution of actions; saving; coping with pending modifications; value help request processing; reacting on data changes; retrieving data; and retrieving properties.
Accordingly, conventional user interface client applications must adapt to services provided by the backend. This adaptation includes an adaptation to backend service layer terms, which are typically meaningless to a user interface developer. User interface terms are also mixed with backend service layer terms during processing of a user interface request in the backend. Mapping between the user interface terms and the backend service layer terms is complex, time consuming, and error prone, particularly if the linkages have to be manually searched over and over by a support technician in a debugger.
The main entities of a backend service layer are “business objects”, which are software model representing real-world entities involved in business transactions. For example, a business object may represent a business document such as a sales order, a purchase order, or an invoice. A business object may also represent master data objects such as a product, a business partner, or a piece of equipment. Particular documents and master data objects (e.g., SalesOrder SO4711, ACME corporation) are represented by instances of their representing business object, or business object instances. Business objects expose their data in a complex, normalized data tree which consists of nodes containing attributes, actions (executing business logic on a node) and associations to other nodes.
A data retrieval service call is complex because it is organized alongside the complex business object tree and because it typically concerns multiple business objects. Since such calls occur often, their execution exhibits the greatest effect on system performance. The service layer and the underlying business objects provide a change notification mechanism in order to allow consumers to implement optimized data retrieval based upon data changes. This mechanism notifies consumers of which business object node instances were created, deleted or updated. Therefore, in case of changes, the consumers only retrieve the dedicated changes, and not the whole business object node tree.
However, for at least the foregoing reasons, it may be difficult for a service consumer to handle the retrieval of the business object node data, the corresponding data buffering and the reaction to any data change. In a case that data is changed and immediately retrieved after each change, not only is the data read multiple times, but the change notifications must be evaluated multiple times. If the aforementioned change notification handling is missing or too coarse, data changes may result in repeated reading of the whole data tree. Unnecessary data retrieval also may result from isolated reactions to change notifications or reading data without a defined order. This processing can result in “ping-pongs” between UI components during backend processing, which are hard to support/understand and entail a significant performance cost due to unnecessary service calls.